III.FHIR 周邊內容

07 Dicom影像介紹

昨天談完了非常晦澀的Terminology，是我也不太懂裡面細節的一個主題，今天來談DICOM，

醫療數位影像傳輸協定（DICOM，Digital Imaging and Communications in Medicine）是負責定義醫學影像標準的的協定，
由美國電氣製造商協會（National Electrical Manufacturers Association）NEMA管理，
該協定以TCP/IP為基礎應用，不同的醫事機構彼此間能夠透過DICOM格式傳輸醫療影像檔案，

以概觀來看，DICOM幾乎覆蓋了醫學影像的多數範疇，如CT, X-ray, MRI, 超音波等檢查，
這個特性保證了無論是什麼形式的影像檢查都能以DICOM進行傳輸交換，而因為這些影像格式被統一了，
醫學儀器的設備商也會對DICOM進行支援，確保自己的設備產出的影像能夠以DICOM呈現，增加互通性。

DICOM還有另一個優勢是，格式內本身還包含了病患的資料、使用的設備等周邊訊息，
能讓臨床人員更完整的判斷該醫學影像所具備的醫學意義。

並且，DICOM由於產製的設備在標準上有嚴格要求，當影像檔案是JPG, PNG等常見資料格式，會有機會被竄改，
DICOM檔案在DICOM Viewer等軟體的閱覽上僅提供後期檢視調整，如調整明暗對比等操作，降低了被竄改的可能性。

從DICOM的結構來看，.dcm檔案包含了兩個大的主要範圍：

 1. 醫學影像數據：包含醫學影像的數位媒體內容
 2. 周邊數據：記錄了該影像的周邊資訊、如被拍攝者的資料、拍攝的設備、拍攝的日期、拍攝的部位等。
 
此外，DICOM檔案通常會透過PACS(醫療影像儲存與傳輸系統)來管理或傳送，
醫事人員能夠透過PACS很容易的存取病患的影像資料，並且分析彼此的臨床差異以利診斷。

當然，有些醫療檢查項目不僅只會拍攝一張影像，有些時候(如CT)，會逐切面拍攝人體，這時候該檢查的項目就會有多張影像，
你可能拿到的DICOM檔案會有兩種分類：

 1. 副檔名為.dcm的單個DICOM檔案
 2. 副檔名空白，但資料夾頂端會有一個DICOMDIR的索引檔案
 
這兩種檔案形式都能使用，以健保上傳資料來說，官方要的是DICOMDIR的形式，
DICOMDIR是影像光碟的呈現型態，DICOM Viewer可以匯入DICOMDIR來讀取資料夾內的所有影像檔案。

詳細的結構細節可以看
https://imediface.blogspot.com/2012/01/dicomdir.html
https://www.airitilibrary.com/Publication/Index/10188940-200302-28-1-21-24-a
會有更詳細的介紹

前面大致講完了DICOM是什麼了，那DICOM要如何與FHIR協作呢?

這邊就要先來把玩一下DICOM檔案，去實際了解一下DICOM檔案內部所包含的內容。

網路上有非常多DICOM Viewer可以使用，也有開源軟體能夠自行使用或建置修改，這邊推薦WEASIS
https://weasis.org/en/

Weasis是開源免費的DICOM VIEWER，本身也相對輕量化，支援OpenCV的Lib，能提供相對高效的影像性能，

台灣這邊有DICOM實驗室推出的bluelight 開源的DICOM Viewer，特色是可以在網頁上顯示3D VR與閱覽的操作系統
https://github.com/cylab-tw/bluelight
https://cylab-tw.github.io/bluelight/bluelight/html/start.html

以Weasis來舉例，當我們開啟任意一個DICOM檔案時，我們可以在上方橫列中找到<> Open DICOM Information，

點開後我們可以看到一整個關於這個DICOM影像的周邊資料，包含

Patient：病患的姓名、ID(病歷號)、性別與生日等病患的基本資訊。
Station：執行產製該DICOM影像的設備製造商、設備與ID
Study：該DICOM影像的執行主分類資訊
Series：在Study之下的一個DICOM檢查系列
DICOM Object：該Series之下的其中一個例子(Instance)
Image Plane：關於該影像的圖像資訊
Image Acquisition：如何得到該影像(檢查的劑量、數據等)

中間三項Study、Series與DICOM Object是相對抽象但很重要的屬性項，這是DICOM的代碼定義，

影像報告會包含三個層級，也就是上面提的Study、Series與Instance，

以一次醫學影像檢查來說，假設檢查的是全身CT好了，

Study代表的是該次檢查的主條目，一次檢查、一次看診就等於一筆Study。

Series是在該次檢查中所使用的檢查類型，如X-ray, MRI等。

Instance則是在這些不同的檢查類型Series中，單張或連續的影像。

從層級上來理解，Study包含了多個不同檢查類型的Series，
而因為一種檢查中可能包含多張影像，也就是Instance，在這之中我們需要關注的是Study、Series與Instance的UID，這些就是用來填入FHIR的重要資料

有人會說，FHIR不就只是一個資料格式嗎，這些填入的DICOM UID也沒有辦法去點閱，
FHIR能做的只有提供索引，標註這個Resource中，影像是在指附件中DICOM的哪一張影像，因此上傳的時候
FHIR文件跟DICOMDIR提供的功能類似，是去導引到標註的那張影像。

在FHIR的架構中，DICOM影像被儲存在ImagingStudy Resource中，
但讓醫事人員或資訊人員手動將DICOM影像的UID填入聽起來也挺沒效率的，
於是乎，DICOM實驗室也實作了一個能將DICOM檔案轉換成ImagingStudy的程式
https://github.com/cylab-tw/dicom-to-fhir
https://cylab-tw.github.io/dicom-to-fhir/Server/index.html

但本地端需要有一台DICOM Server才能使這個工具正常使用，如何抉擇就見仁見智

在FHIR的ImagingStudy Resource中，FHIR需要填答的欄位有幾個
(以下取自 https://nhicore.nhi.gov.tw/pas/ImagingStudy-imaStu-min.json.html)

"identifier" : [
    {
      "system" : "urn:dicom:uid",
      "value" : "urn:oid:2.16.886.2102.54.4546465747.465465465"
    }

identifier內首先填入的是DICOM的Study UID，作為該ImagingStudy的唯一識別碼，

在下方的屬性項內，則會有Series與Instance兩個欄位：

"series" : [
    {
      "uid" : "2.16.886.2102.54.4546465747.465465466",
      "modality" : {
        "system" : "http://dicom.nema.org/resources/ontology/DCM",
        "code" : "CT"
      },
      "bodySite" : {
        "system" : "http://snomed.info/sct",
        "code" : "774007",
        "display" : "Head and neck structure"
      },
      "instance" : [
        {
          "uid" : "2.25.88017001449189502323411118737039844241",
          "sopClass" : {
            "system" : "urn:ietf:rfc:3986",
            "code" : "urn:oid:1.2.840.10008.5.1.4.1.1.2"
          }
        }
      ]
    }
  ]

 
在series中，除了必須要填入Series的UID外，FHIR還要求要填入檢查的項目別與檢查部位，盡可能與DICOM的原生檔案契合。

要特別注意的是，ImagingStudy中的各個uid是不需要搭配system使用的，因為其只對應到DICOM的UID，

至於sopClass，可以查詢

https://www.dicomlibrary.com/dicom/sop/

或詢問影像人員該填入的資料。

明天要正式討論IG、Profile、Bundle等Resource，特別是Bundle因為本身具有多種用途與應用意義，我想花一個範圍來談

另外IG的品質對於實作至關重要，如何定義一個好的IG讓申請端與接收端都能夠更完整的統合所需要的資訊。